[Build] Remove SWT library version information built into binaries #1939
Conversation
HannesWell
force-pushed
the
no-builtin-library-version
branch
5 times, most recently
from
1728e61 to
4395e91
Compare
|
I have investigated the outcome of this change a bit further and noticed that the initially removed For Linux and Mac this PR effectively changes nothing. It just removes some declared compiler constant that define library-version information that is not referenced. The only real change is for the native-library binaries for Windows as this removes the file-version information from the metadata that is e.g. displayed in the
But as this simplifies releng tasks and moreover allows to make the (native) build more robust and to lower future growth of Git large-file storage occupation via #1940 I think this is worth it. |
HeikoKlare
left a comment
HeikoKlare
left a comment
There was a problem hiding this comment.
The idea sounds good to me. I never had a need fpr the DLL version metadata, so I am fine with removing them. I second your assessment of favoring robust builds and less growing files over the usually unused metadata.
Only scenario I in which I would see a need for them is if they would be installed to Windows and a matching version is searched for while dynamically linking against the SWT library. But I don't think this is a relevant scenario that has ever been used (I am not even sure if it's possible the way I imagine it).
This removes all native/library version information that is currently built into the native binaries of SWT (only) for Windows. It also removes declared constants that define such values for C-compilers from the build-scripts for all platforms, as they are not used (anymore, for Windows). Consequently the library-version information is only captured in the name of the native binary files and in the 'Library' java class. The previously built-in version-information (in the Windows binaries) is not used anywhere by SWT. It was just displayed if one inspected the 'Details' sectuin in the Properties-dialog of Windows file-explorer. With this removal it becomes possible to just rename the binary files in case just the library version has changed without a change in the native sources. This happens for example if only the native sources for another platform are changed.
HannesWell
force-pushed
the
no-builtin-library-version
branch
from
4395e91 to
d0aacb3
Compare
You mean another (native) application is compiled against the SWT native libraries? I don't think that this is a use-case that was ever considered for SWT. At least I'm not aware that for the binaries any promises regarding API/ABI-stability are made. |
2 participants
This removes all native/library version information that is currently built into the native binaries of SWT.
Consequently the library-version information is only captured in the name of the native binary files and in the 'Library' java class.
The previously built-in information is not used anywhere in SWT.
This allows to just rename the binary files in case just the library version has changed without a change in the native sources. This happens for example if only the native sources for another platform are changed.